[% setvar title The Perl 6 Summary for the week ending 20030427 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030427'></a><h1>The Perl 6 Summary for the week ending 20030427</h1>
<p>Welcome back to (I hope) a normal length summary of Perl 6 shenanigans
after last week's bumper double length installment. (Thankfully
traffic has been much lighter this week; I'm not sure I could cope
with writing another epic.)</p>
<p>Perl6-internals was quiet again this week, but traffic does appear
to be picking up a little.</p>
<a name='IMC and Variable Number of Arguments'></a><h2>IMC and Variable Number of Arguments</h2>
<p>Following on from questions on this subject last week, Klaas-Jan Stol asked
for some clarification of Parrot calling conventions as documented in
Parrot Design Document (PDD) 03. In a subsequent post he noted that it
seems strange that the current perl6 implementation (such as it is)
doesn't follow the Parrot calling conventions. Sean O'Rourke shuffled
his feet slightly and admitted that he'd chosen that method because
&quot;It was easiest&quot;, though he'd later rationalized that to &quot;It doesn't
matter for internal calls&quot;. Dan Sugalski pointed out that it was only
a temporary aberration. Unless I missed something, nobody actually
answered Klaas-Jan's initial questions.</p>
<p><a href='http://groups.google.com/groups?threadm=004301c30836$2bb7d530$6401a8c0@deepblue' target='_blank'>groups.google.com</a></p>
<a name='Short-lived memory allocation'></a><h2>Short-lived memory allocation</h2>
<p>Last week, in a discussion of the Garbage Collection (GC) system, Dan
mentioned that Parrot GC would walk the system stack in order to build
the Root Set (the list of memory 'nodes' that are initially known to
be alive) which makes life a good deal easier for anyone allocating
memory because they don't have to worry about explicitly attaching
their shiny new buffer to the root set. Of course, it doesn't lessen
the pain of whoever writes the GC system because, as Benjamin Goldberg
pointed out, any system stack walking system is inherently
unportable.</p>
<p>Benjamin was concerned that there may be systems where, not only could
you not use the same stack walking code as was used everywhere else,
but it would be impossible to walk the system stack at all. Dan
admitted that there 'used to be' such systems, but asserted that, for
Parrot's purposes &quot;Either we get access to the C auto variable chain,
or we can't run there.&quot; Kurt Stephens pointed at some deeply scary
sounding (and gloriously non-portable) system stack walking methods
which involve co opting the C stack pointer and collecting garbage from
unlikely places...</p>
<p>If you're not sure what is meant by 'Walking the system stack' then
you're not alone. Tim Howell asked for clarification and received it
from Matt Fowles and Brent Dax.</p>
<p><a href='http://groups.google.com/groups?threadm=3EA5F617.DF8C2E43@earthlink.net' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=86671D11624E2944A477B1E7AB38DC16A6048F@exchange.fefcful.org' target='_blank'>groups.google.com</a></p>
<a name='PMC Documentation'></a><h2>PMC Documentation</h2>
<p>Alberto Sim&otilde;es continued on his mission to document Parrot's
various PMC classes. This week he offered up some Perlstring documentation</p>
<p><a href='http://groups.google.com/groups?threadm=20030423072628.GA3286@alfarrabio.di.uminho.pt' target='_blank'>groups.google.com</a></p>
<a name='The Native Call Interface (NCI) system.'></a><h2>The Native Call Interface (NCI) system.</h2>
<p>Michael Collins has been playing around with calling C from Parrot and
found the NCI system rather cumbersome. He wondered if the whole thing
couldn't simply be implemented with a <code>callcfunc</code> opcode and showed a
simple implementation of what he was driving at. Dan replied to this,
explaining that he'd considered it but that it turns out not to be the
Right Thing, and gave his reasons to do with encapsulation (when you
call a PMC's method you shouldn't have to know whether it's written in
C, PASM or Befunge) and issues with dynamic generation of stub
functions. Michael wasn't entirely convinced by Dan's argument.</p>
<p>On the subject of NCI, Clinton A Pierce wondered if it is supposed to
be Win32 capable and, if it was, what he needed to do to get it
working as his first attempt had failed. Currently on the horns of
Warnock's Dilemma.</p>
<p><a href='http://groups.google.com/groups?threadm=1413.192.168.1.3.1051146003.squirrel@www.ivorycity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030424121644.00b34a68@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<a name='use for p6c'></a><h2><code>use</code> for p6c</h2>
<p>Joseph F. Ryan resent his patch to implement <code>use</code> in Parrot's Perl 6
implementation, this time as a straight CVS diff on Steve Fink's
request.</p>
<p><a href='http://groups.google.com/groups?threadm=3EA73A7E.9000403@osu.edu' target='_blank'>groups.google.com</a></p>
<a name='Building on Win32'></a><h2>Building on Win32</h2>
<p>Matthia Barbon continued his sterling work on getting Parrot to play
well with Win32, offering a couple of patches. Steve Fink applied them
both.</p>
<p><a href='http://groups.google.com/groups?threadm=Mahogany-0.64.2-1156-20030424-234320.00@rbnet.it' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030427074312.GB2717@foxglove' target='_blank'>groups.google.com</a></p>
<a name='External Data Interfaces draft PDD'></a><h2>External Data Interfaces draft PDD</h2>
<p>Matthia Barbon redrafted Brent Dax's External Data Interfaces PDD
based on the discussion of the original document. This elicited a few
comments and I presume we can expect another, clarified draft at some
point.</p>
<p><a href='http://groups.google.com/groups?threadm=Mahogany-0.64.2-1156-20030424-234520.00@rbnet.it' target='_blank'>groups.google.com</a></p>
<a name='PPC JIT questions'></a><h2>PPC JIT questions</h2>
<p>Peter Montagner has started to work on the Just In Time (JIT) system
for the PowerPC architecture (a chap can get tired of making sure that
every initialism is expanded at least once in a document you
know. Still, it's been a few summaries since I last did anything like
this) and had a couple of questions about its architecture and what he
was allowed to do in PPC assembly. Dan answered, Peter asked for
clarification; the usual give and take.</p>
<p><a href='http://groups.google.com/groups?threadm=EEE7E67C-7712-11D7-B7FC-000393934DD6@postinbox.com' target='_blank'>groups.google.com</a></p>
<a name='A question about encoding'></a><h2>A question about encoding</h2>
<p>Speed junkie Luke Palmer (Hmm... that may not mean quite what I want
it to mean) is working on the next iteration of <code>string_str_search</code>,
which, apparently isn't fast enough (it's still slower than Perl
5). He had a few questions about encodings. Benjamin Goldberg offered
answers and an entire function. Luke was impressed, but he still
muttered about how much faster single byte searching could be (he's
written a singlebyte/singlebyte search routine that goes slightly more
than 2.5 times faster than Perl 5 apparently).</p>
<p>Later, Luke posted a new implementation of <code>string_str_search</code> which
used his screamingly fast algorithm for single byte searching and a
'stupid, slow algorithm' for multibyte searches. Steve Fink applied
the patch and asked for a unified diff next time as they are easier to
read.</p>
<p><a href='http://groups.google.com/groups?threadm=20030427032624.42EECC5@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=ygcel3o9ygf.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Leo T&ouml;tsch's iterator proposal'></a><h2>Leo T&ouml;tsch's iterator proposal</h2>
<p>Remember Leo T&ouml;tsch's iterator proposal that received so little
feedback a few weeks back? Steve Fink finally commented.</p>
<p><a href='http://groups.google.com/groups?threadm=20030427083919.GF2717@foxglove' target='_blank'>groups.google.com</a></p>
<a name='uniq.pasm and Parrot IO'></a><h2>uniq.pasm and Parrot IO</h2>
<p>About a month ago, J&uuml;rgen B&ouml;mmels was doing some work on the
moving Parrot's IO operators to use Parrot's own PIO asynchronous IO
system, which broke Leon Brocard's <b><i>uniq.pasm</i></b>. J&uuml;rgen
estimated that he might have it working 'next weekend'. This week Leon
asked if any progress had been made yet.</p>
<p><a href='http://groups.google.com/groups?threadm=20030427085548.GA27550@kanga.astray.com' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>The Type discussions continued. (Though I note, with some satisfaction
that most of the discussions died down after I posted the
summary. Maybe I got it right. Or not.)</p>
<a name='Types'></a><h2>Types</h2>
<p>Michael Lazzaro's excellent summary of what we knew about Types served
as the seed for this particular discussion, which was essentially a
continuation by other title of the thread that started last
week. Discussion centred on ways of specifying what sorts of type
coercions should be automatic and which disallowed. Paul Hodges
suggested <code>use strict allow =&gt; { Int =&gt; Str, Foo =&gt; Bar }</code> as a
possibility, which doesn't quite work where you want to allow a type
to convert to more than one possible target type, but it does look
like a reasonable start.</p>
<p>There was also discussion of autocoercion to different types via a
'path' of coercions which looks to like it has enormous potential for
complexity based nuisance. Michael Lazzaro reckoned that a lot of the
chaining problems would go away if you drew a distinction between a
'lossless' coercion to a string and a serialization of something to a
string for the purposes of debugging or whatever. (Coercing *from* a
string to almost any other type but a numeric one seems to be the hard
problem...)</p>
<p>Damian offered some thoughts about user defined coercions when he
pointed out that a coercion is really an interaction between two
classes and should therefore be implemented using a multimethod. He
argued that things like Coercions were a strong argument for allowing
return type to be incorporated into the multidispatch resolution
mechanism. Others agreed that this would be a good thing, and we await
a decision from Larry.</p>
<p><a href='http://groups.google.com/groups?threadm=95A29C02-71EF-11D7-BA15-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Seed</p>
<p><a href='http://groups.google.com/groups?threadm=010201c307a0$a9ee62c0$36e7403e@server' target='_blank'>groups.google.com</a> -- This week's 'root'</p>
<p><a href='http://groups.google.com/groups?threadm=3EA34EF9.4070205@conway.org' target='_blank'>groups.google.com</a></p>
<a name='Change in 'if' syntax'></a><h2>Change in 'if' syntax</h2>
<p>The Subject of the thread still thinks the discussion is about a
change in the syntax of <code>if</code>, but it's actually about a change in how
a block is recognized, which has knock on effects on on the syntax of
various control structures, of which <code>if</code> is just one
example. Various people balked (again) at the fact that the new rules
for detecting a block mean that code like <code> %foo {bar}</code> no longer
means &quot;find the value associated with 'bar' in the hash %foo&quot; but
instead evaluates to a hash variable followed by a block, and probably
a syntax error soon afterwards. Michael Lazzaro and Damian showed
workarounds for this (<code>%foo .{bar}</code> and <code>%foo{ bar}</code> respectively)
and Arcadi Shehter reminded everyone of the space eating <code>_</code> that
seems to have been completely forgotten since the last time this issue
arose.</p>
<p><a href='http://groups.google.com/groups?threadm=m23cka629e.fsf@TiBook.bofh.org.uk' target='_blank'>groups.google.com</a></p>
<a name='anon-sub()'s execute in a for??'></a><h2><code>anon-sub()</code>'s execute in a for??</h2>
<p>Paul Hodges took a crack at implementing <code>for</code> as a subroutine and
came up with something that didn't look too insane. Luke Palmer added
a refinement allowing for n at a time looping. However, for reasons
that I can't quite put my finger on, I'm not quite sure that either
method has got the sub signature quite right, and I'm not entirely
sure how you would express <code>for</code>'s signature as a Perl 6 signature
anyway. Answers on a mailing list please.</p>
<p><a href='http://groups.google.com/groups?threadm=20030422171801.35742.qmail@web41204.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='* vs **'></a><h2><code>*</code> vs <code>**</code></h2>
<p>Paul Hodges wondered about the <code>*</code> and <code>**</code> flattening operators. He
wondered if they were actually distinct operators or if the double
variant was simply the result of applying <code>*</code> to the results of
<code>*@whatever</code>. According to Larry, the two are distinct, the only
difference between them is one of timing. I'm not sure I understood
the distinction to be honest and I don't think I'm alone in
this. Austin Hastings asked for an illustrative example, but we didn't
see any before the end of the week.</p>
<p><a href='http://groups.google.com/groups?threadm=20030422215146.432.qmail@web41204.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='P6Objects: Hint's allegations and things unsaid'></a><h2>P6Objects: Hint's allegations and things unsaid</h2>
<p>Austin Hastings' response to last week's mammoth Types discussion was
a mammoth document of his own on what is currently known about Perl
6's Object Orientation features which was the result of trawling back
through about two years of perl6-language postings. And jolly good it
is too. It triggered a modest amount of discussion, but my theory is
that everyone was too impressed to say much. I know I was.</p>
<p><a href='http://groups.google.com/groups?threadm=ICELKKFHGNOHCNCCCBKFKEAMCEAA.Austin_Hastings@Yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Storing program state for restarting'></a><h2>Storing program state for restarting</h2>
<p>Ed Peschko wondered if it would be possible to serialize the state of
a running program so that it could pick up where it left off after it
died at the point of expiry. Dave Storrs suggested that, if one could
just serialize the current continuation, the problem would become
trivial (I'm not entirely sure he's right about that though; the
current continuation seems to me to be in slightly the wrong place)
and asked how one could do such a thing. The answer appears to be 'to
the best of current research's knowledge, you can't generally do that,
but we're working on it...'.</p>
<p><a href='http://groups.google.com/groups?threadm=20030422152656.A17489@mdssirds.comp.pge.com' target='_blank'>groups.google.com</a></p>
<a name='C-struct style data reads'></a><h2>C-struct style data reads</h2>
<p>Paul Hodges doesn't like <code>pack</code>. What he wants to be able to do is
something akin to C's:</p>
<pre>    struct {
        int   someInt;
        float someFloat;
        char  strData[42];
        float otherFloat;
        char  moreStr[123]
    } buf;
    fread(buf, sizeof buf, 1, fp);
    printf(&quot;%.0f %s&quot;, buf.someFloat, buf.moreStr);</pre>
<p>instead of unpacking a string with <code>unpack &quot;ifa43fa123&quot; &lt;$file&gt;</code>
or whatever. This led to some discussion of appropriate syntax and the
like, but it was generally felt that, even if something like this
wasn't in the core, it wouldn't be too hard to implement it.</p>
<p><a href='http://groups.google.com/groups?threadm=20030423151120.47160.qmail@web41206.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Return types vs. Generic Programming'></a><h2>Return types vs. Generic Programming</h2>
<p>Michael Lazzaro wants the moon on a stick. In particular he wants to
be able to declare:</p>
<pre>   class Object { method CLONE returns MAGIC_TYPE {...} }</pre>
<p>where MAGIC_TYPE is some magical token that means not having to
declare</p>
<pre>   class Whatever { method CLONE returns Whatever { .NEXT::CLONE } }
   class Whoever  { method CLONE returns Whoever  { .NEXT::CLONE } }</pre>
<p>Quite what's wrong with</p>
<pre>   class Object { method CLONE returns Object {...} }</pre>
<p>is a mystery to me. Luke Palmer wants more than that. The insanity
continued for several messages.</p>
<p>Do you get the feeling that I'm not a fan of this particular proposal?
I confess I'm finding it very hard to summarize it any more than the
above without exclamations of shock and dismay. So I'll stop now. Read
the thread if you're interested.</p>
<p><a href='http://groups.google.com/groups?threadm=09747A96-75AF-11D7-BB99-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Type Conversion Matrix'></a><h2>Type Conversion Matrix</h2>
<p>Michael Lazzaro posted a matrix of some of the known built in types
and of the possibilities of conversion between them, noting that what
was shown were the conversions that it was possible to make automatic,
not necessarily those which should be automatic. For some reason this
led to a discussion of boolean types. Nope, I don't know why either.</p>
<p>Another subthread discussed which conversions were lossy and whether
or not to make them automatic in the case of going from, say 'Int' to
'int'. (Int being a Perl Integer which could be undef and have
properties and traits, and 'int' being, essentially, at least 32 bits
of signed integer).</p>
<p>Michael posted a second take on the matrix with more information and
with an additional 'Scalar' type added to it.</p>
<p><a href='http://groups.google.com/groups?threadm=9B96DAF4-75C3-11D7-BB99-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=B223400E-767E-11D7-9AE3-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Fun with Junctions'></a><h2>Fun with Junctions</h2>
<p>Austin Hastings got faintly confused by the difference between 'all'
and 'any' junctions. The rule of thumb appears to be 'if you want to
use a junction to represent a set, use an &quot;any&quot; junction.'</p>
<p><a href='http://groups.google.com/groups?threadm=20030423203739.3147.qmail@web12302.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Fun with multi-dimensional arrays'></a><h2>Fun with multi-dimensional arrays</h2>
<p>Dave Whipp pointed everyone at a discussion of Perl 6 on Perlmonks,
where people were implementing J H Conway's Game of Life in Perl. Dave
had a some questions about tools for iterating over multidimensional
arrays, suggesting some syntax as he went, then pulling it all
together in a rather neat recalculation engine for the game of life.</p>
<p>Things got scary pretty quickly after that; at one point Dave even did
a local redefinition of <code>infix:=</code> which certainly had me
worried. Some clever stuff going on there and no mistake.</p>
<p><a href='http://groups.google.com/groups?threadm=20030427004929.88458.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.perlmonks.org/index.pl?node_id=253366' target='_blank'>www.perlmonks.org</a></p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>That about wraps it up for this week.</p>
<p>If you've appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or some proof that people read this bit to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, photographic and writing commissions, or
some proof that people read this bit to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
</div>
